“원활한 ERP 통합”은 흔히 듣게 되는 약속이지만, 실제로는 3개월간의 프로젝트가 뒤따르는 경우가 많습니다. 귀사의 IT 부서가 계약 체결 전에 실제로 어떤 정보가 조회되는지 확인할 수 있도록, 당사는 API 플레이북을 공개합니다. 통합 프로젝트를 시작하기 전에 알아두어야 할 사항은 다음과 같습니다.
ERP가 실제로 제공해야 할 사항
DPP를 구축하기 위해서는 제품별로 다음 정보가 필요합니다.
- 마스터 데이터 - 품목 번호, 명칭, 변형, 중량, 치수, 이미지
- BOM(자재명세서) 데이터 - 수량 및 재활용 재료 비율이 포함된 구성품
- 원산지 데이터 - 생산지, 로트 번호, 생산일
- 환경 데이터 - 단위당 CO2eq, 물 소비량, 에너지 소비량
- 공급업체 데이터 - 누가 어떤 부품을 공급하는지 (실사 용도)
이론적으로 귀사의 ERP에는 이러한 데이터가 모두 존재합니다. 실제로는 이 데이터들이 4~7개의 모듈에 분산되어 있습니다: 자재 관리(MM), 생산(PP), 품질(QM), 공급업체(LFA1), 때로는 환경 데이터를 위한 별도의 EHS 모듈, 때로는 레시피를 위한 PLM 시스템 등이 있습니다.
통합에 관한 핵심 질문은 “귀사의 ERP가 DPP에 데이터를 제공합니까?”가 아닙니다. “5개의 하위 시스템에 분산된 데이터를 어떻게 하나의 일관된 데이터 세트로 통합할 것인가?”입니다.
검증된 세 가지 통합 패턴
패턴 1: OData / REST 풀(Pull)
최신 ERP(SAP S/4HANA Cloud, Dynamics 365, Odoo)에서 잘 작동합니다. DPP 공급업체가 OData 또는 REST를 통해 데이터를 가져옵니다. 증분 방식, 예약 방식 또는 이벤트 기반 방식.
장점: 귀사의 개발 부담이 적으며, 귀사는 읽기 인증 정보를 제공하고 공급업체가 변환 로직을 구축합니다.
단점: 추가 API 계층이 없는 구형 SAP ECC 설치 환경에서는 작동하지 않습니다. 데이터 액세스 요청에 대한 거버넌스가 필요합니다.
패턴 2: 이벤트 기반 통합
SAP Event Mesh, Apache Kafka, RabbitMQ. 귀사의 ERP가 변경 이벤트를 발행하면, DPP 공급자가 이를 수신합니다.
장점: 거의 실시간 처리, 유연한 확장성, 분리된 아키텍처.
단점: 구성이 까다롭고, 모든 IT 부서가 갖추고 있는 것은 아닌 인프라가 필요합니다. 소규모 기업에는 대체로 과도한 사양입니다.
패턴 3: 미들웨어 / ETL
ERP와 외부 시스템 사이에 통합 계층(Mulesoft, Boomi, Informatica, Azure Data Factory)이 있습니다. 미들웨어가 중개자 역할을 합니다. DPP 공급업체는 미들웨어와 통신하며, ERP와 직접 통신하지 않습니다.
장점: 기존 투자를 활용할 수 있으며, 거버넌스가 안정적이고, 제3자가 ERP에 직접 접근할 수 없습니다.
단점: 미들웨어 비용도 함께 증가합니다.
구체적인 프로젝트에서 우리가 다르게 접근하는 방식
많은 공급업체들이 귀사의 ERP와 직접 연결되기를 원합니다. 우리는 원칙적으로 중간 단계를 도입합니다. 당사의 API는 중립적인 JSON 스키마를 수용하며, 귀사는 원하는 도구를 사용하여 이 스키마에 데이터를 채울 수 있습니다. 즉:
- 귀사 팀이 익숙한 도구를 사용하여 데이터를 직접 전처리할 수 있습니다
- 중립적인 형식 덕분에 다른 공급업체로 전환할 수 있습니다
- CSV, XLSX, JSON-LD, SQL 형식 및 REST API를 통해 언제든지 전체 데이터를 다시 가져올 수 있습니다
- 업로드 전에 데이터를 검증해 주는 임포트 검증 도구를 제공합니다
전체 스키마와 모든 엔드포인트는 /apidocs에서 OpenAPI 사양으로 공개되어 있습니다. 계약 체결 전에 귀사의 IT 팀이 인터페이스를 검토할 수 있습니다. 여기에는 예시 요청, 오류 응답 및 인증 세부 정보가 포함됩니다.
이 접근 방식을 실제 적용할 때의 일정:
- 1~2일차: 매핑 워크숍. ERP의 어떤 필드가 DPP의 어떤 필드에 대응되는지 결정합니다.
- 3~5일차: ERP에서 첫 번째 JSON 내보내기 수행, 당사 유효성 검사기를 통해 검증.
- 6~8일차: 오류 수정(누락된 필드, 불일치하는 코딩).
- 9~10일차: 첫 번째 DPP가 가동됩니다.
3개월이 아닌 2주. 핵심은 매핑 워크숍입니다. 바로 이곳에서 데이터 품질이 결정됩니다.
잘못될 수 있는 점: 가장 흔한 함정
여러 시스템에 분산된 제품 마스터 데이터: SAP에는 품목 번호가, PIM에는 이미지와 마케팅 문구가, PLM에는 BOM(자재명세서)이 있습니다. 어느 쪽도 일관된 정보를 가지고 있지 않습니다. 해결책: 프로젝트 시작 전에 어떤 시스템이 어떤 필드에 대해 ‘Source of Truth’인지 정의하십시오.
PDF 형식의 인증서: 공급업체가 GOTS, OEKO-TEX 또는 REACH 인증서를 PDF 스캔 파일로 제공합니다. 이는 구조화된 데이터 소스가 아닙니다. 해결책: 인증 기관들이 점차 API 조회 서비스를 제공하고 있습니다(OEKO-TEX가 앞서고, GOTS는 뒤처지고 있습니다). 또는: 수동으로 입력하되, 유효 기간을 함께 기재하여 DPP에 만료된 인증서가 표시되지 않도록 합니다.
처방 비밀 유지: 특히 화장품, 식품 및 제약 분야에서 전체 처방은 영업 비밀입니다. DPP가 이를 공개해야 합니까? 해결책: ESPR의 3단계 모델. 제품 카테고리는 공개되고, 당국은 전체 성분 정보를 확인합니다. 거의 문제가 되지 않지만, 조기에 명확히 해야 합니다.
공급업체 기준 CO₂ 데이터: 귀사의 공급업체는 배치별이 아닌 전체 포트폴리오에 대한 평균값을 제공합니다. 해결책: 당분간은 이를 수용하고, 장기적으로는 공급업체 계약을 조정하십시오. ESPR은 특정 기준일 이후부터 제품별 수치를 요구하지만, 현재 관행은 타협안입니다.
현지 언어 버전: 귀사의 ERP에는 독일어와 영어로 된 제품명만 포함되어 있습니다. 27개 EU 국가를 위해서는 더 많은 언어가 필요합니다. 해결책: 용어 데이터베이스를 활용한 기계 번역. 이에 대해서는 별도의 기사가 있습니다.
프로젝트 시작 전에 확인해야 할 질문들
세 곳의 공급업체에 RFP를 발송하기 전에, 내부적으로 다음 질문에 답해 보십시오:
- DPP에 포함될 제품/품목 번호는 몇 개입니까? (10개, 10,000개, 100만 개?)
- 현재 어떤 시스템에 DPP 관련 데이터가 저장되어 있습니까?
- 각 시스템을 관리하는 부서는 어디인가요?
- 활용해야 할 미들웨어 투자가 있나요?
- ERP 위에 이미 작동 중인 API 계층이 있나요?
이 답변들에 따라 세 가지 모델 중 어떤 것이 귀사에 적합한지 결정됩니다. 또한 프로젝트 기간이 2주일지 6개월일지도 이 답변들에 따라 결정됩니다.